# Troubleshooting

If you're running into issues with Wiredoor, here are some common problems and how to solve them.

---

### Wiredoor CLI says “unauthorized” or “invalid token”

- Ensure you're using a **valid token** for a node created in the Web UI
- If you're using `wiredoor login`, verify the admin credentials
- Rotate the token using `wiredoor regenerate` if needed

---

### I exposed a service but it’s not reachable

Check:

- The **VPN connection is active** (`wiredoor status`)
- The **port** is correct and the service is listening on the node
- The **domain points to your Wiredoor server**
- The node is **connected** in the Wiredoor UI
- No NetworkPolicy is blocking access (for Kubernetes Gateway)

---

### I can’t connect to my Wiredoor Server

- Ensure ports **80**, **443**, and **VPN_PORT (UDP)** are open
- Use `curl` or `ping` to check connectivity to the server domain/IP
- Verify Docker is running and the container is healthy

---

### DNS doesn’t resolve service names in Kubernetes

- Confirm you’re using a **fully qualified name** like `my-service.default.svc.cluster.local`
- Make sure the service is running and exposed in the correct namespace

---

### Let’s Encrypt certificate isn’t generated

- The domain must resolve publicly to your Wiredoor Server IP
- Port **80** must be open for HTTP validation

---

### Services show SSL warnings

- You're likely using a **self-signed certificate** (internal domain)
- To avoid warnings, use a public domain and allow Wiredoor to handle Let's Encrypt

---

### The Wiredoor Gateway Pod can’t access my service

- Make sure it runs in a namespace with access
- Use Helm's `networkPolicy.egress` to allow the right Pod/Namespace
- Ensure the service is on the same subnet defined in the gateway node

---

### How can I view logs?

For server logs:

```bash
docker logs wiredoor
```

If you're still having trouble, open an issue on GitHub or join the community for help!

### Gateway node cannot reach internal network IPs

If you're using a **Wiredoor Gateway node** and it cannot reach IPs in the target internal network, make sure to check the following:

- IP forwarding is enabled:

```bash
sysctl -w net.ipv4.ip_forward=1
```

- **SELinux (on RedHat-based systems): ** Ensure that SELinux is not blocking forwarding or masquerading. You may need to adjust policies or set SELinux to permissive mode for testing:

```bash
setenforce 0
```

- Firewall Masquerading is enabled (firewalld):

```bash
firewall-cmd --permanent --add-masquerade
firewall-cmd --reload
```
